Network service functions, SFs, or middleboxes are essential elements in operators' networks, which perform various traffic processing tasks in order to provide desired service sets and meet required Service-Level Agreements, SLAs. Such functions can be linked into sequences, thus creating service function chains, SFCs. For instance, subscriber's traffic may need to pass through Firewall, DPI, Traffic Optimizer and Network Address Translation, NAT, in Internet Service Provider, ISP, network on its way towards Internet. Depending on the service policies and traffic classes, the set and the sequence of functions in a chain may vary significantly. Service functions can dynamically react on incoming traffic modifying packets, flows or sessions, redirecting and terminating them. Moreover, SFCs can be reorganized dynamically either by operator's policies—through Network Monitoring/Management System, NMS—or in reaction to their in-line operation. However, traditional L2/L3 forwarding mechanisms in ISP networks cannot meet steering requirements introduced by presence of SFCs. Considering that in modern architectures SFs can be virtualized, mobility and horizontal scaling introduce additional issues for dynamicity of SFCs.
Today common SFC steering deployments are mainly implemented with manual and static low-level configurations of forwarding equipment using either L3 routing, policy-based routing, traffic engineering protocols, tunneling mechanisms or combinations of these techniques. Such approaches are hardly scalable, error prone and lack dynamicity and centralized control for applicability of abstracted service policies. Besides, many SFs perform modifications of packets on higher levels—L4-L7—and require corresponding high-granular steering decision. Whereas, forwarding engines cannot recognize these modifications neither in-line nor through any signaling mechanisms between transport network and SFs. That leads to non-optimal SFC architectures with coarse and inefficient SFC policies and, as a result, additional performance costs of SFs.
Current research approaches to solve steering issues, introduced by SFCs, mostly try to implement transfer of additional SFC metadata, which can carry both steering policies and traffic context required by SFs. Relative to underlying transport network, this metadata can be transferred either in-band, out-of-band or in a hybrid mode. Several in-band and hybrid approaches propose to transfer metadata within existing unused packet headers, see “FlowTags: Enforcing Network-Wide Policies in the Presence of Dynamic Middlebox Actions” at website cs.princeton.edu/courses/archive/fall13/cos597E/papers/flowtags.pdf, “SIMPLE-fying Middlebox Policy Enforcement Using SDN” at website ece.cmu.edu/˜ece739/papers/simple.pdf and “Stratos: A Network-Aware Orchestration Layer for Virtual Middleboxes in Clouds” at website arxiv.org/pdf/1305.0209v2.pdf. However in that case forwarding equipment should be aware of such injections and has to be able to implement forwarding policies according to provided metadata. In most cases this requires significant modifications of underlying transport network equipment. Apart, scalability issues may arise as transfer of metadata usually exploits overheads with fixed and small number of bits—Differentiated Service Code Point, DSCP, Type of Service, ToS, etc. Others propose to introduce additional packet headers, e.g. “Network Service Header” IETF Draft at website tools.ietforg/html/draft-quinn-nsh-02, for transfer of SFC metadata and to encapsulate traffic in overlay networks between service endpoints using tunneling mechanisms—VXLAN, NVGRE, STT. These architectures commonly require significant modification of termination points—usually software switches in hypervisors—and additional performance costs.